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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



This document defines the stage-2 service description for emergency services in the IP Muhimedia Core Network 
Subsystem (IMS), including the elements necessary to support IP Multimedia (IM) emergency services. 
ITU-T Recommendation 1.130 [4] describes a three-stage method for characterisation of telecommunication services, 
and ITU-T Recommendation Q.65 [3] defines stage 2 of the method. 

This document covers also the Access Network aspects that are crucial for the provisioning of IMS emergency services. 
Other 3GPP specifications that are related to the IMS emergency services are TS 23.228 [1] on IMS in general, 
including fixed broadband access aspects, TS 23.060 [2] and TS 23.234 [7] describing GPRS and 3GPP/WLAN 
Interworking respectively and TS 23.271 [5] that covers location services. TS 25.301 [6] contains an overall description 
of the UMTS Terrestrial Radio Access Network. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [11] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [11]. 

Connectivity Session Location and Repository Function (CLF): As per ETSI ES 282 004 [18], the Connectivity 
Session Location and Repository Function (CLF) registers the association between the IP address allocated to the UE 
and related network location information, i.e.: access transport equipment characteristics, line identifier (Logical Access 
ID), IP Edge identity. 

Emergency Call Server (ECS): The functional entity consists of a Location Retrieval Function (LRF) and either a 
routing proxy or a redirect server, e.g. an ECS contains a VPC and a Routing Proxy or Redirect Server in NENA 12 
architecture [17]. 

Emergency-CSCF: The Emergency-CSCF handles certain aspects of emergency sessions, e.g. routing of emergency 
requests to the correct emergency centre or PSAP. 

Emergency Service Query Key (ESQK): A 10-digit North American Numbering Plan number used to identify a 
particular emergency call instance. It is used by the LRF as a key to look up for the location information and callback 
information associated with the emergency call instance and is also used by the PSAP to query location information 
from the LRF. 

Emergency Service Routing Key (ESRK): see TS 23.271 [5]. 

Emergency Service Routing Number (ESRN): North American Numbering Plan number used for routing of an 
emergency call to the appropriate gateway for an eventual delivery towards a CS-based PSAP. 

Geographical Location Information: Location indicated in geographical terms, for example geographical coordinates 
or street address (e.g. as supported by IETF RFC 41 19 [14]). 

IP-Connectivity Access Network (IP-CAN): The collection of network entities and interfaces that provides the 
underlying IP transport connectivity between the UE and the IMS entities. An example of an "IP -Connectivity Access 
Network" is GPRS. 

Location Identifier: Information about the current location of the UE in the network. Location is indicated in network 
terms, for example using the global cell id in cellular networks, line-id in fixed broadband networks, (OMA-Location 
also uses this term, but OMA so far defines the Location Identifier only for cellular access.) 
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Location Information: The location information may consist of the Location Identifier, and/or the Geographical 
location information. 

Location Retrieval Function (LRF): This functional entity handles the retrieval of location information for the UE 
including, where required, interim location information, initial location information and updated location information. 
The LRF may interact with a separate RDF or contain an integrated RDF in order to obtain routing information. The 
LRF may interact with a separate GMLC or contain an integrated GMLC in order to obtain location information. The 
LRF may interact with or contain other types of location server functions in order to obtain location information. 

Last Routing Option (LRO): A number, which may be used in the event of network failure towards a specific location 
based PSAP or a number that can be associated to a national or default PSAP/Emergency centre. 

Public Safety Answering Point (PSAP): A physical location, where emergency calls from the public are received. 

Routing Determination Function (RDF): The functional entity, which may be integrated in a Location Server (e.g. 
GMLC) or in an LRF, provides the proper PSAP destination address to the E-CSCF for routing the emergency request. 
It can interact with a location functional entity (e.g. GMLC) to manage ESQK allocation and management, and deliver 
location information to the PSAP. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

CLF Connectivity session Location and repository Function 

E-CSCF Emergency-CSCF 

ECS Emergency Call Server 

ESQK Emergency Service Query Key 

ESRK Emergency Service Routing Key 

ESRN Emergency Service Routing Number 

LRF Location Retrieval Function 

LRO Last Routing Option 

PSAP Public Safety Answering Point 

RDF Routing Determination Function 



4 High level Principles 

4.1 Architectural Principles 

The solution for emergency sessions in the IMS fulfils the emergency principles and requirements of TS 22.101 [8] and 
the following architectural requirements: 

L Void. 

2. Emergency services are independent from the IP -CAN with respect to the detection and routing of emergency 
sessions. The emergency services shall be possible over at least a cellular access network, a fixed broadband 
access, I-WLAN access and a nomadic access. 

3. Any kind of emergency numbers, and emergency SIP and TEL URIs as specified in TS 22.101 [8], and special 
indications for emergency sessions within the SIP signalling shall be supported. 

4. Emergency sessions should be prioritized over non-emergency sessions by the system. 

5. The establishment of IMS emergency sessions shall be possible for users with a barred public user identity. 

6. The primary solution shall be that the UE can detect an emergency session (e.g. by evaluating the SIP-URI or the 
dialled number) by itself and indicates the emergency session to the network. The cases where the UE can't 
detect an emergency session shall also be supported. 
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7. The solution shall work in case the UE has sufficient credentials to authenticate with the IMS and is registered to 
the IMS or is not registered with the IMS. The case where the UE does not have sufficient credentials to 
authenticate with the IMS shall also be supported where regulations allow. 

In the case that UE is not already IMS registered, it shall perform a registration for the support of emergency 
services (emergency registration). 

In the case a UE is already IMS registered, the UE may skip the additional emergency registration if the UE is 
aware that it is in its home network (e.g. including IP-CANs where roaming outside the home network is not 
supported). 

Editor's Note: The usage of local routing numbers in North America to call back the roaming user without involving the 
home network is FFS. 

If the UE does not have sufficient credentials to authenticate with the IMS it shall be possible to perform session 
establishment without an existing security association between UE and P-CSCF, and the UE shall include an 
equipment identifier (the specific details of the equipment identifier to use may depend upon the IP -CAN) in the 
request to establish an emergency session. 

8. It shall be possible to reject emergency service requests from an UE, without sufficient credentials to 
authenticate with the IMS in networks where emergency services from UEs with sufficient credentials to 
authenticate with the IMS are required. 

9. Emergency Service is not a subscription service and therefore will mainly be supported in the roamed-to 
network. In the case that a UE has sufficient credentials, it shall initiate an emergency registration with the 
network (requiring the involvement of the home network). The CSCFs providing service for emergency sessions 
may be different from the CSCFs involved in the other IMS services. In the case that the registration fails, the 
UE may attempt an anonymous emergency call. 

10. If an emergency session establishment request is routed to a P-CSCF located in the home network, the home 
network should be able to detect that the session is for emergency service (whether indicated as such or not) and 
respond to the UE indicating that the UE should initiate an emergency session in the visited network (e.g. via the 
CS domain of the visited network). 

11. Emergency centers and PSAPs may be connected to the PSTN, CS domain, PS domain or any other packet 
network. 

12. Emergency centres and PSAPs shall be able to call back the user for an emergency session from a UE that has 
registered (i.e. containing valid credentials). 

13. The IMS core network shall be able to transport information on the location of the subscriber. 

14. Void. 

15. The network shall be able to retrieve the caller's location; 

16. As a regional option, the network shall be capable of assigning a routable location key (i.e. Emergency Services 
Query Key, a.k.a. ESQK, which has the same properties as the existing ESRK in wireless 911 services) to an 
IMS emergency session, and releasing the ESQK when the emergency session is terminated. 

17. The network shall provide the caller's location information to the PSAP upon query from the PSAP. 

18. The network shall provide the possibility to route to a default answering point given the scenario where the local 
PSAP can not be determined. 

19. The network may provide a capability to enable a UE to obtain local emergency numbers. 

20 A UE should support a capability to obtain local emergency numbers from the network once such a capability 
has been defined and agreed. 

21. It shall be possible to prevent the sending of the information of the users, such as public user identifiers and the 
location information to the PSAP when explicitly requested by the user, i.e. request on session by session basis. 

22. The Emergency Public User Identifier shall only be used for emergency services and not for other services. 
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NOTE: TS 24.008 [13] contains a procedure to provide local emergency numbers for UMTS and GPRS access but 
the procedure is not applicable to 1-WLAN and contains a limited number of emergency service categories. Therefore, 
an improved capability may need to be developed for IMS Emergency calls. 

In addition to the architectural requirements, the following architectural principles apply to IMS emergency sessions: 

The IMS network shall be able to discriminate between emergency sessions and other sessions. This shall allow 
special treatment (e.g. with respect to filtering, higher priority, routing, QoS) of emergency sessions. 

If a visited network can support PS emergency service, the emergency session shall be established in the visited 
network whether or not UE is registered in IMS in the home network. 

The P-CSCF is the IMS network entity, which is responsible to detect the request for emergency session and 
forwards the request to E-CSCF in the same network. 

The P-CSCF serving the emergency call is the IMS network entity which may retrieve the location identifier 
from the IP-CAN. 

The E-CSCF is the IMS network entity, which shall be able to retrieve geographical location information from 
the LRF in the case that the geographical location information is not available and is required. 

If required, the E-CSCF shall be able to forward the location information to the LRF for validation of 
geographical location information in the case that the geographical location information is included by the UE 
over any access network type. 

The E-CSCF is the IMS network entity, which is responsible to route the request to an emergency centre/PSAP 
or BGCF based on location information and additionally other information such as type of emergency service in 
the request. 

4.2 Naming and Addressing 

The UE shall use a special emergency Public User Identifier in the emergency registration request. The implicit 
registration set of the emergency Public User Identifier shall contain an associated Tel URL 

4.3 Location information for Emergency Sessions 

Location information is needed for 2 main reasons in emergency services. The initial purpose of the location 
information is to enable the IMS network to determine which PSAP serves the area where the UE is currently located, 
so that the IMS network can route the emergency session to the correct PSAP. The second purpose is for the PSAP to 
get more accurate or updated location information for the terminal during or after the emergency session. 

4.3.1 General Location Information Principles 

The following general principles shall apply regarding the handling of location information: 

If the UE has location information available, the UE shall include the location information in the request to 
establish an emergency session. The location information may consist of network location information, that is 
the Location Identifier, and/or the Geographical location information. 

The P-CSCF may query the IP-CAN to obtain location identifier. The E-CSCF, if required, may query the LRF 
for additional location information. If the E-CSCF does not receive location information in the emergency 
service request, it may query the LRF for location information. 

The E-CSCF shall be able to query the LRF to validate the location information if provided initially by the UE. 

The E-CSCF routes the emergency request to the PS AP/Emergency Centre that corresponds to the current 
location of the UE or to a default PSAP/Emergency Centre. The access dependent variations of this approach are 
described below, for the cases where the UE is using GPRS, I-WLAN or fixed broadband access for the 
emergency service. 
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The E-CSCF forwards the SIP request containing the UE's location information to the PSAP/Emergency Centre 
or BGCF/MGCF. The location information can contain explicit location information and/or a reference key to 
allow the PSAP to retrieve location at a later stage. 

4.3.2 Void 
4.4 IP-CAN 

The following are the expectations on the IP -CAN for IMS emergency services: 

It shall be possible to access the IP -CAN without sufficient security credentials. 

It shall be possible to reject requests from UE without sufficient security credentials to establish bearer 
resources: 

In the case that the IP -CAN receives a request to establish bearer resources for emergency services, it 
shall be possible for the IP -CAN to prioritise emergency services traffic. PCC (Policy and Charging 
Control) methods may be used to inform the IP -CAN and request appropriate handling of the 
emergency service. The QoS information for emergency traffic is specified in TS 23.203 [20]. 

In the case that the IP-CAN receives a request to establish bearer resources for emergency services, the IP -CAN 
shall ensure that the IP flows using the requested resources are only for communication with the network entities 
involved in the support of the emergency services. Applicable service data flow filters for emergency traffic 
need to be defined by the operator according to the details described in TS 23.203 [20]. 

The IP -CAN may support emergency services free of charge. Applicable PCC rules need to be defined by the 
operator according to the details described in TS 23.203 [20]. 

The IP -CAN may provide emergency numbers to the UE in order to ensure that local emergency numbers are 
known to the UE (see TS 22.101 [8]). 

In case the IP-CAN is a GPRS network, the detailed procedures are described in the TS 23.060 [2]. 

5 Architecture model and reference points 

5.1 Reference architecture 

This specification introduces an additional CSCF role to those defined in the IMS architecture TS 23.002 [12], called 
Emergency CSCF (E-CSCF), see figure 5.1. 
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Figure 5.1 : E-CSCF in reference architecture 

NOTE 1: P-CSCF and E-CSCF are always located in the same network; this is the visited network when the UE is 
roaming. 

NOTE 2: For simplicity, not all functional components, e.g. IBCF, I-CSCF, MGCF and BGCF, are shown in this 
figure. 

NOTE 3: It shall be possible, for example in the North America regions, to support configurations where the Location 
Retrieval Function (LRF) may consist of a Routing Determination Function (RDF) and a Location Server (e.g. GMLC), 
the interface between Location Server and RDF is out of scope of this specification. The RDF may be integrated in the 
Location Server (e.g. in the LRF). 

NOTE 4: Based on local policy, the E-CSCF may route the emergency IMS session to the PSAP via an ECS. See the 
details in Annex D. 



5.2 Reference points 



The E-CSCF uses Mw, Mr, Mg, Mi, Ml, and Mm reference points to connect to other IMS entities. 

6 Functional description 

6.1 UE 

Should be able to detect an emergency session establishment request. 

Use a special emergency Public User Identifier in the IMS emergency registration request. 

The UE may perform an IMS emergency session establishment without prior emergency registration when 
already IMS registered and it is in home network (e.g. including IP-CANs where roaming outside the home 
network is not supported). 

Otherwise, the UE shall perform an IMS emergency registration. 
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Include an emergency service indication in the emergency session request. 

Include an equipment identifier in the request to establish an emergency session for "anonymous user". 

NOTE: "Anonymous user" in this context is the person who does not have sufficient credential for IMS registration. 
No Stage 3 work is expected as the anonymous user detection already existed today. 

Attempt the emergency call in CS domain, if capable. 

Handle a 380 (Alternative Service) response with the type set to "emergency" as a result of emergency attempt. 

Handle a response with an indication, IMS emergency registration required as a result of emergency session 
establishment attempt. 

Other general requirements of UE shall be referred to the general requirements of emergency calls in 
TS 22.101 [8]. 

The UE initiates the emergency session establishment request, and for the purpose of processing the request properly in 
the network the following specific information is supplied in the request message. 

Emergency session indication. 

Emergency Public User Identifier if an IMS emergency registration is performed. If not, any registered Public 
User Identifier is used. 

Optionally, type of emergency service. It could be implied in the above emergency session indication. 

UE's location information, if available. 

The Tel URI associated to the emergency Public User Identifier, if available. 

6.2 IMS Functional entities 
6.2.1 Proxy-CSCF 

Handle registration requests with an emergency Public User Identifier like any other registration requests except 
that the registration expiration. P-CSCF may set the proposed registration expiration time according to the local 
policy and change the expiration value in the REGISTER requests, and then forward the request to the IBCF or 
I-CSCF in the user's home network. 

NOTE: If the registration expiration time is changed by the P-CSCF in the visited network, the S-CSCF in the home 
network should obtain the proposed registration expiration value from the REGISTER request and use the same 
registration expiration time. 

Detect an emergency session establishment request. 

Reject/allow unmarked emergency requests. 

Reject/allow anonymous emergency requests. 

Prevent the assertion of an emergency Public User Identifier in non-emergency requests 

May query IP-CAN for location identifier. 

Select an Emergency CSCF in the same network to handle the emergency session request. The selection method 
is not standardized in the present document. 

Prioritize the emergency session. 

Check the validity of the caller Tel URI if provided by the UE and shall provide the Tel URI in the session 
establishment request if it is aware about the Tel URI associated with the emergency Public User Identifier. 

May response to the UE with an indication, IMS emergency registration required as a result of processing the 
emergency session establishment attempt. 
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Should be able to identify the service data flow associated with emergency service and 
inform PCRF accordingly. 

6.2.2 Emergency-CSCF 

Receive an emergency session establishment request from a P-CSCF. 

If location information is not included in the emergency request or additional location information is required, 
the E-CSCF may request the LRF to retrieve location information as described in subclause 7.6 Retrieving 
Location information for Emergency Session. 

If required, the E-CSCF requests the LRF to validate the location information if included by the UE. 

Determines or queries the LRF for the proper routing information/PS AP destination. 

Route emergency session establishment requests to an appropriate destination including anonymous session 
establishment requests. 

Subject to national requirements, the E-CSCF may send the contents of the P-asserted ID or UE identification to 
the LRF. 

Based on local policy, the E-CSCF may route the emergency IMS call to ECS for further call process. 

6.2.3 Location Retrieval Function 

The Location Retrieval Function (LRF) is responsible for retrieving the location information of the UE that has initiated 
an IMS emergency session. It shall be possible to support configurations where the Location Retrieval Function (LRF) 
may consist of a Routing Determination Function (RDF) and a Location Server (e.g. GMLC), the interface between 
Location Server and RDF is out of scope of this specification. 

The LRF utilizes the RDF to provide the routing information to the E-CSCF for routing the emergency request. The 
RDF can interact with a location functional entity (e.g., GMLC) and manage ESQK allocation and management. The 
ESQK is used by the PSAP to query the LRF for location information and optionally a callback number. The LRF- 
PSAP interactions are outside the scope of this specification. 

Information provided by the LRF to the E-CSCF includes the routing information and other parameters necessary for 
emergency services, which are subject to local regulation. For example, this information may include the ESQK, ESRN, 
LRO in North America, location number in EU, PSAP SIP URI or Tel URL 

In order to provide the correct PSAP destination address to the E-CSCF, the LRF may require interim location 
information for the UE. 

In some regions, for example in the North American region, it may be a requirement to provide the PSAP with an 
accurate initial location estimate for the UE and possibly to provide an accurate updated location estimate for the UE if 
requested by the PSAP. When this requirement exists, the LRF may store a record of the emergency session including 
all information provided by the E-CSCF and shall only release this record when informed by the E-CSCF that the 
emergency session has terminated. The information provided by the LRF to the E-CSCF (e.g. ESQK) shall then include 
correlation information identifying both the LRF and the emergency session record in the LRF. This correlation 
information shall be transferred to the PSAP during session establishment (e.g. in a SIP INVITE or via SS7 ISUP 
signalling from the MGCF). The PSAP may use this information to request an initial location estimate from the LRF 
and/or to request an updated location estimate. 
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7 Procedures related to establishment of IMS 

emergency session 

7.1 High Level Procedures for IMS Emergency Services 
7.1 .1 UE Detectable Emergency Session 

The following flow contains a high level description of the emergency service procedures performed when the UE can 
detect the emergency session is being requested. 
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Figure 7.1 : Terminal Detected Emergency Calls 

The following steps are performed: 

1 . The UE detects the request for the establishment of an emergency session. Step 2 to 6 may be skipped based on 
the conditions specificed in clause 6. 1 . 

2. In the case that the UE has insufficient resources or capabilities to establish an emergency call due to other 
ongoing sessions then the UE should terminate the ongoing communication and release reserved bearer 
resources 

3. In the case that bearer registration is required and has not been performed, the UE shall perform bearer 
registration to the IP-CAN. If the UE is already bearer registered, then the bearer registration procedures are not 
required to be performed. 

NOTE 1 : Depending on the IP-CAN, the UE may be assigned an IP address at this stage. 

4. In the case that bearer resources for the transport of the IMS related signalling are required to be reserved in the 
IP-CAN, the UE shall reserve the resources in the IP-CAN. The UE shall provide an indication that this is for an 
emergency service. 

If the IP-CAN does not provide an IP address to the UE in step 3, then the IP -CAN shall allocate an IP address to 
the UE during the bearer resource request procedures. 

5. UE performs a P-CSCF discovery procedure, where the UE discovers a P-CSCF in the local network suitable for 
use in emergency sessions. 

NOTE 2: The exact means for the P-CSCF discovery is dependant upon the IP-CAN. 
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6. If the UE has sufficient credentials to authenticate with the IMS network, it shall initiate an IMS emergency 
registration by providing the IP address obtained at step 3 or step 4 to the P-CSCF selected at step 5. The IP 
address used for signalling purposes is allocated in association with step 3 or step 4. The IMS registration request 
shall include an Emergency Public User Identity. The implicit registration set of the emergency Public User 
Identifier shall contain an associated Tel URI that is used to call back the user from the PSTN. 

The P-CSCF may set the proposed registration expiration according to the local policy and change the 
registration expiration in the REGISTER request. An indication may be added to explicitly indicate that the 
expiration has been set by the visited network. When the S-CSCF in the home network receives the REGISTER 
request, the S-CSCF should obtain the proposed registration expiration value from the request and use the same 
registration time. The S-CSCF should return the response containing the same registration expiration to the UE. 
The sequent registration flows are like any other registration. 

If the UE does not have sufficient credentials to authenticate with the IMS network, it shall not initiate an IMS 
emergency registration request, but instead immediately establish an emergency session towards the P-CSCF as 
described in step 7. 

7. If IMS emergency registration is performed, the UE shall initiate the IMS emergency session establishment 
using the IMS session establishment procedures containing an emergency session indication and emergency 
Public User Identifiers. Otherwise, the UE shall initiate the IMS emergency session establishment using the IMS 
session establishment procedures containing an emergency session indication and any registered Public User 
Identifier. 

Whether the procedures are activated individually by the UE or some of them are performed automatically depends on 
the implementation of the terminal and on the UE's configuration. For instance, the multimedia application in the UE 
could start the application level registration and steps 2-4 would have to be executed in response to support the 
operation initiated by the application. Interaction with the UE may happen during these steps. 

7.1 .2 Non UE detectable Emergency Session 

As the UE could not detect the emergency session, the session establishment request will be sent to a P-CSCF in the 
visited PLMN or a P-CSCF in the home PLMN as per a normal session establishment procedure. The former is only 
applicable to a roaming situation whereas the latter can apply to both a roaming and non-roaming situation. Prior to 
sending the session establishment request the UE must be registered in the IMS as per the normal registration 
procedure. 

In the case that the P-CSCF detects that this is a request to establish an emergency session, based upon local policy 
(e.g., checking access type): 

the P-CSCF may reject the session initiation request with an indication that this is for an emergency session. 
When the UE receives the session rejection then the UE shall either attempt to initiate an emergency call in the 
CS domain or follow the procedure in 7. 1 . 1 . 

- Alternatively, the P-CSCF in the visited PLMN or the P-CSCF in the home PLMN for a non-roaming UE may 
allow the session initiation request to continue by inserting the explicit emergency indication in the session 
request and forward that request to an Emergency CSCF in the same network. There is no requirement to inform 
the UE that the session has been marked as an emergency session, i.e. the UE can treat the session as a normal 
session establishment. 
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7.1 .3 Emergency Session Establishment using LRF/RDF 

Figure 7.2 illustrates a high level call flow for the IMS emergency session establishment procedure using LRF/RDF to 
retrieve location and routing information. 



UE 



IMS 
Network 



LRF 
(RDF) 



MGCP/ 
MGW 



PSAP 
/EC 



1. UE initiates tiie emergency 
session 



r 



1 2. if required, retrieve UE 



I location 



I 3. if required, retrieve PSAP 



routing information 



4. E-CSCF routes the emergency session based on routing 
destination from LRF 



Figure 7.2: Emergency Session Establishment procedure with using LRF/RDF 

1 . UE initiates an emergency session request by sending a SIP INVITE message with including emergency URL 

2. If required, the IMS network may access the LRF to retrieve the UE's location. 

3. If required, LRF invokes the RDF to determine the proper PSAP destination. LRF returns the necessary 
location/routing information (e.g., ESQK for North America or location number for EU) to the IMS network. 

4. The IMS network uses the routing information returned by the LRF to route the emergency session request 
towards the appropriate PSAP. 

NOTE: If the LRF provides an ESQK to the IMS network in step 3 or assigns any other dedicated resource to the 
emergency session, the IMS network shall inform the LRF when the session is released in order to allow the LRF to 
release this resource. 

7.2 IMS Registration for Emergency Session 

The IMS emergency registration procedure shall follow the procedures as described in subclause 5.2.2.3 of 
TS 23.228 [1] with the following modifications: 

The UE shall initiate an IMS emergency registration when all of the following conditions are met: 

either the UE is not already IMS registered or the UE is IMS registered but is roaming outside its home 
network; 

the UE has sufficient credentials to authenticate with the IMS network; 

the UE is able to detect emergency session. 

The UE shall also initiate an IMS emergency registration when it receives an "IMS emergency registration 
required" response as a result of the emergency session request. 

The UE shall use an emergency Public User Identifier in the emergency registration request. This indication may 
be used to route calls coming from the PSAP to the contact address registered during the emergency registration 
procedure and to inform the home network that roaming restrictions may not be applied. The format of this 
public user identity has to be defined by stage 3. 

The user's home network should ignore roaming restrictions for emergency registration requests. 
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No originating and terminating services should be applied to emergency Public User Identifiers. 

NOTE: The special emergency public user identifier is difl'erent fi^om emergency indication in the IMS emergency 
session establishment request. 

P-CSCF handles the registration requests with an emergency Public User Identifier like any other registration requests 
except that the registration expiration. P-CSCF may set the proposed registration expiration time according to the local 
policy and change the expiration value in the REGISTER requests, and then forward the request to the IBCF or I-CSCF 
in the user's home network. 

If the registration expiration time in the REGISTER request is changed by the P-CSCF, the S-CSCF in the home 
network should obtain the proposed registration expiration value from the request and use the same registration 
expiration time. The S-CSCF should return the response containing the same registration expiration to the UE. The 
sequent registration flows are like any other registration. 

7.3 Emergency Session Establishment in the Serving IIVIS 
network 

If the UE is able to detect that the user is requesting an emergency session then it shall include an emergency service 
indication in the emergency session establishment request. 

If the UE is CS capable and not attached to the PS domain, the UE shall attempt an emergency call in the CS domain. If 
the UE is only PS attached, and the network has indicated that IMS emergency services are supported, it should attempt 
the emergency call in the PS Domain. If the UE is attached to both domains, it should follow the requirement as stated 
in TS 22.101 [8] that specifies "A CS and IMS capable UE attempting an emergency call should give priority to the CS 
Domain. In case the call attempt fails, the UE should automatically make a second attempt on the other domain". For an 
attempt in the IM CN Subsystem of the PS domain, the attempt should be in the serving (visited if roaming) IM CN 
Subsystem of the PS domain. 

If the initial attempt is in the CS domain and it fails, the serving (visited if roaming) IM CN Subsystem of the PS 
domain shall be attempted if the UE is capable. If the initial attempt is in the IM CN Subsystem of the PS domain and it 
fails, the UE shall make the attempt in the CS domain (if the UE is capable and if for an appropriate service e.g., voice). 

If a UE attempts to initiate a session and receives a 380 (Alternative Service) response with the type set to "emergency", 
the UE shall then re-attempt the session as described above with first attempt being towards the CS domain (if the UE is 
capable and if for an appropriate service e.g., voice), and with an indication that emergency service is requested. 

If the UE is aware that it does not have sufficient credentials to authenticate with the IMS network, it shall not initiate 
an IMS registration but immediately establish an emergency session towards the P-CSCF, see subclause 7.4. 

Upon receiving an initial request for an emergency session, the P-CSCF shall follow the rules and procedures described 
in TS 23.228 [1] with the following additions and clarifications: 

The P-CSCF is the IMS network entity, which detects an emergency session. 

A P-CSCF in the home network should, when it can recognise the emergency number or emergency indication, 
respond to the UE indicating that the UE should initiate an emergency session in the visited network (e.g. via the 
CS domain of the visited network). 

For the case that the initial request carries an indication that the request is for emergency services, and the UE is 
not registered in the IMS network, see subclause 7.4 for details. 

For the case that UE is IMS registered and the initial request does not carry an indication that the request is for 
emergency services, and the P-CSCF is able to detect that the request is for emergency services, the P-CSCF 
shall perform the " Non UE detectable Emergency Session " described in subclause 7.1.2 above. 

On receipt of a session establishment request, which is recognized to be for an emergency service, the P-CSCF 
shall check whether the UE provided a Tel URI as its identity in the request. If a Tel URI is present in the 
request, the P-CSCF shall check the validity of this Tel URI. If no Tel URI is present in the request and the 
P-CSCF is aware about the Tel URI associated with the emergency Public User Identifier, it shall provide the Tel 
URI to the E-CSCFin the session establishment request. 

The P-CSCF may query the IP-CAN for the location identifier. 
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P-CSCF shall prioritize emergency sessions over other non-emergency sessions. 

Emergency IP flows need to be identified by P-CSCF in the Rx interface signalling to 
allow the PCRF to prioritize emergency service data flows over non-emergency service 
data flows within IP -CAN. The detailed procedures are specified in TS 23.203 [20]. 
Upon receiving an initial request for an emergency session from P-CSCF, the E-CSCF shall perform the following: 

if location information is not included in the emergency service request or if additional location information is 
required, the E-CSCF, if required, retrieves the UE's location information as described in subclause 7.6 
Retrieving Location information for Emergency Session. 

If location information is included by the UE, the E-CSCF, if required requests the LRF to validate the location 
information. 

May determine or may request the LRF to determine the appropriate routing information which could be based 
on the type of emergency service requested and UE's location. 

Editor's Note: This "routing" interface and RDF interaction is FFS! It is expected that the input parameter to the RDF to 
determine the proper PS AP routing is location information, user's identity, and type of emergency service requested. 

Editor's Note: Location interface and E-CSCF interaction is FFS! 

Editor's Note: How the IMS network routes the emergency session based on location information is FFS. 

determine the default PSAP destination if routing based on UE's location is required but the location is unknown. 

If the PSAP/emergency centre contains a point of presence within the IMS connectivity network, the E-CSCF 
shall forward the emergency session initiation request directly to the PSAP/emergency centre. 

If the PSAP/emergency centre has its point of presence in the PSTN/ISDN network or the CS domain, the 
E-CSCF uses the Tel-URI obtained from the LRF and forwards the request to an appropriate BGCF/MGCF for 
routing in the GSTN. This number shall have the same format as used for CS emergency calls. The MGCF may 
insert any available location information in the PSTN/CS signalling. 

NOTE: In case an ESRN is received from the LRF, the E-CSCF maps the received ESRN from the LRF to a TEL- 
URI before forwarding the request to MGCF. 

7.4 IMS Emergency Session Establishment without Registration 

When the UE initiates an emergency session establishment without prior IMS registration, it shall include both the 
"anonymous user" and "emergency service" indications in the emergency session establishment request to the P-CSCF. 

Based on local policy, the P-CSCF may reject "anonymous user" emergency session establishment with appropriate 
error code. UE shall not reattempt the "anonymous user" emergency session again via the same network. 

When P-CSCF accepts the "anonymous user" emergency session establishment, it forwards this request to an 
appropriate E-CSCF although no security association between UE and P-CSCF is established. 

The E-CSCF shall follow the same rules and procedure as defined for the Emergency Session Establishment in the 
Serving IMS network in subclause 7.3 to route the anonymous emergency session. 

Editor's Note: Location aspect with anonymous user is FFS ! 

7.5 Interworking with PSAP 

7.5.1 PSAP/Emergency centre located at the GSTN 

No special procedure is defined. PSAP uses the MSISDN (E.164) of the user for call back. 

7.5.2 PSAP/Emergency centre connected via IP using SIP 

No special procedure is defined. PSAP uses any public user identity that it has received from the user for call back. 



£75/ 



3GPP TS 23.167 version 7.5.0 Release 7 



20 



ETSI TS 123 167 V7.5.0 (2007-06) 



7.5.3 PSAP/Emergency centre connected via ECS 

No special procedures are identified in IMS Core, the routing determination will be performed by the ECS. 

7.6 Retrieving Location information for Emergency Session 
7.6.1 Acquiring location information from tine UE or tlie network 

When performing an emergency service, four scenarios for retrieving location information for routing purposes are 
considered: 

the UE knows its own location; 

the UE retrieves its location information from the network; 

the IMS core retrieves the location information. The related high level procedures are described below; 

location information is not needed to route the emergency call by the IMS core, optionally the emergency 
routing determination and location information retrieval may be performed by the Emergency Call Server (ECS) 
as part of the emergency session establishment procedure. In this case, the IMS core does not need to obtain the 
location information. See the details in Annex D. 
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Figure 7.6-1 : Handling of location information in IMS emergency calls 

1 . The user initiates an emergency call. 
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2. The UE determines its own location or location identifier if possible. If the UE is not able to determine its own 
location, the UE may, if capable, request its location information from the IP-CAN, if that is supported for the 
used IP -CAN. If applicable, the IP-CAN delivers to the UE the UE's geographical location information and/or 
the location identifier. 

3. The UE sends an INVITE with an emergency indication to the IMS core. The INVITE should contain any 
location information that the terminal has. The location information may be geographical location information or 
a location identifier, which is dependant upon the access network technology. In case the UE is not able to 
provide any location information, the IMS core may seek to determine the UE's location from the LRF as 
described below. The INVITE may optionally contain information concerning the location solutions and position 
methods supported by the UE. 

NOTE: the location solutions and position methods conveyed in the INVITE and the means of inclusion in the 
INVITE are outside the scope of this specification. 

4. If the location information provided in step 3 is trusted and sufficient to determine the correct PS AP, the 
procedure continues from step 7 onwards. If the location information is insufficient or if the IMS core requires 
emergency routing information, or if the IMS core is required to validate the location information, or if the IMS 
core is required to map the location identifier received from the UE into the corresponding geographical location 
information, the IMS core sends a location request to the LRF. The request shall include information identifying 
the IP-CAN and the UE and may include means to access the UE (e.g. UE's IP address). The request shall also 
include any location information provided by the UE in step 2. The request may optionally include any 
information concerning the location solutions and position methods supported by the UE. 

4. The LRF may already have the information requested by IMS core or LRF may request the UE's location 
information. The means to obtain the location information may differ depending on the access technology the 
UE is using to access the IMS. With GPRS access the PS-NI-LR or PS-MT-LR procedures defined in 
TS 23.271 [5] may be used. The SUPL procedures defined in OMA AD SUPL: "Secure User Plane Location 
Architecture" [15], OMA TS ULP: "User Plane Location Protocol" [16], may be used if supported by the 
terminal and if it is possible to establish a user plane connection between the UE and the SUPL server. 
Information provided in step 4 concerning the location solutions and position methods supported by the UE may 
optionally be used by the LRF to help determine the means to obtain the location information. 

The LRF may invoke an RDF to convert the location information received in step 4 or obtained in step 5 into 
PS AP routing information, but LRF's interactions with RDF are out of scope of the present specification. The 
LRF may store the location information, but only for a defined limited time in certain regions, according to 
regional requirements. 

6. The LRF sends the location information and/or the routing information to the IMS core. The LRF may also 
return correlation information (e.g. ESQK) identifying itself and any record stored in step 5. 

7. The IMS core uses the routing information provided in step 6 or selects an emergency centre or PSAP based on 
location information provided in step 3 or 6 and sends the request including the location information and any 
correlation information and possibly location information source, e.g., positioning method that was used to 
obtain the location information to the emergency centre or PSAP. 

7a. The INVITE is sent to an MGCF/MGW, 

7b. The lAM is continued towards the emergency centre or PSAP, or 

7c. The INVITE is sent directly to the emergency centre or PSAP. 

8. The emergency call establishment is completed. 

9. The PSAP may send a location request to the LRF to get the initial location information for the target UE, or to 
request LRF to get updated, i.e. current, location information for the target UE. The PSAP may determine the 
LRF based on the location and/or correlation information received in step 7. The PSAP may also include the 
correlation information in the request to the LRF. 

10. The LRF determines the target UE's location using one of the means listed in step 5 above. The LRF may use the 
correlation information received in step 9 to retrieve information about the UE that was stored in step 5. 

1 1. The LRF returns the initial or updated location information to the emergency centre or PSAP. As an option for 
initial location, the LRF may instigate the location step 10 before the request in step 9 is received and may send 
the initial location to the emergency centre or PSAP either after the request in step 9 is received or before it is 
received. 
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12. The emergency call is released. 

13. The IMS core may indicate to the LRF that the call is released. The LRF deletes any record stored in step 5. 

7.6.2 Void 



7.6.3 Void 
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Annex A (informative): 

IIVIS emergency services using GPRS Network 

Editor's Note: The content of this Annex is a place holder until such stage that they are moved to appropriate TS (i.e. 
TS 23.060 [2]). After these contents are moved, this annex will be removed from this specification.. 

A.1 Requirements on the GPRS network as an IP-CAN 

For an emergency call over the GPRS, the requirements on the IP-CAN, as described in subclause 4.3, are covered by 
the following GPRS specific requirements: 

It shall be possible to access the PS domain without a UICC 

It shall be possible to reject requests from a UE without a UICC to establish bearer resources 

A globally dedicated emergency APN shall be used to support PDP contexts for emergency services for roaming 
UEs in VPLMN and for anonymous emergency calls by a UlCC-less terminal. The globally dedicated APN may 
be configured in the SGSN and GGSN. The GGSN may use filter rules applicable to the globally dedicated 
emergency APN to ensure that only certain allowed IP addresses (e.g. IP addresses of the emergency P-CSCF) 
can be reached. When a mobile terminal sends packets to IP addresses other than the allowed IP addresses over 
the PDP context for emergency services, the GGSN drops these data packets. The GGSN may also drop data 
packets addressed to the mobile terminal over a PDP context for emergency services, which are not coming from 
an allowed IP address. 

PCC rules may be used for the emergency service data flow filtering as well as associated policy and charging. 
The emergency service related PCC rules may be pre-defined in the GGSN or dynamically provided by the 
PCRF over Gx interface. Pre-defined PCC rules may be automatically activated by the GGSN for a dedicated 
emergency APN. For non-emergency APN pre-defined emergency PCC rules may be activated dynamically by 
the PCRF. The details of the PCC rules and PCC procedures are specified in TS 23.203 [20]. 

The PS domain may support the download of emergency numbers to the UE via the procedures defined in 
TS 24.008 [13]. 

A.2 UE specific behaviour for emergency calls over the GPRS 

For the specific case of an emergency call over GPRS the UE shall follow the following procedures: 

If not already PS attached, the UE shall perform a PS attach with an indication that this is for emergency use. 

UEs that need to do IMS emergency registration or UlCC-less terminals that are used for an anonymous 
emergency call shall request PDP context activation to a globally dedicated emergency APN. 

The UE shall include the Cell Global Identification (CGI) in the INVITE request establishing the emergency 
call. 

A.3 GPRS specific aspects of High Level Procedures for IMS 
emergency calls 

For the high level procedures (as described in subclause 7.1.1.) the following statements apply for emergency calls 
when GPRS access is used: 

the bearer resource request is the PDP context activation procedure, and the globally dedicated emergency APN 
is used to indicate the emergency request. 

the release of reserved bearer resources is the release of a PDP context. 

the bearer registration to the IP-CAN is the PS attach procedure 
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A.4 Location handling for GPRS 



For access in the PS domain, the UE shall include the access type and cell identity as specified in TS 24.229 [19], clause 
7.2A in the SIP INVITE request, when it initiates an emergency session using GPRS bearer. It is noted that the UE 
normally is not aware of S AI and therefore SAI cannot be used as location information in SIP signalling. 

For regions (e.g. North America) in which an interim location may be required to assist routing to the correct PSAP 
and/or where accurate initial and updated location information may be required, the PS-NI-LR and PS-MT-LR 
procedures defined in TS 23.271 [5] are applicable as well as use of SUPL defined in OMA AD SUPL: "Secure User 
Plane Location Architecture" [15], or OMA TS ULP: "User Plane Location Protocol" [16]. 

NOTE: The use of SUPL procedure is depended on the UE capabilities. 

A. 5 Open Issues on GPRS specific aspects 

Editor's Note: This section will be used to capture and develop open issues that need to be resolved for GPRS access in 
relation of Emergency calls before the contents are moved to TS 23.060 [2]. 

1) How to support an MS in Limited Service state? 

It is assumed that a blocked MS, e.g. an MS camping in a Forbidden Location Area or Forbidden PLMN, see 
TS 23.122, should be able to initiate the IMS emergency service request. Such an MS may be in the so-called 
limited service state. When the UE is in GMM-DEREGISTERED state, it shall execute the Attach procedure and 
when the UE is in GMM-REGISTERED state, it shall perform the RAU procedure. Note that main states have 
several sub-states as defined in TS 24.008 [13] e.g. GMM-REGISTERED.LIMITED-SERVICE (the UE shall do 
RAU) and GMM-DEREGISTERED.LIMITED-SERVICE (the UE shall do Attach). 

Conclusion: when the UE is DEREGISTERED it shall do Attach with the emergency indication included and 
when the UE is REGISTERED it shall do RAU with the emergency indication included. 

2) When shall the MS request Emergency APN? 

The MS requests the Emergency APN in order to ensure that the access point is in the same network as the UE 
itself. From GGSN the MS gets the address of the P-CSCF within the same network and this P-CSCF knows 
which E-CSCF serves the location of the MS. In this way it is possible for IMS and E-CSCF to determine the 
correct PSAP to which IMS shall route the emergency call. 

An MS without a valid UICC needs to request an anonymous IMS emergency call and the only way for such an 
MS to get access is to request the Emergency APN. An MS in limited service state shall always do IMS 
emergency registration first and therefore starts by requesting the Emergency APN. 

Conclusion: The MS shall request Emergency APN whenever it needs to perform IMS emergency registration. 
UlCC-less terminals that are used for an anonymous emergency call shall also request Emergency APN. 

A) How to convey emergency indication in RAU procedures (Intra and Inter)? 

The MS may have done the emergency attach earlier and already included the emergency indication in that 
procedure. There are 2 alternative solutions how to carry on the emergency information in the following RAU 
procedures; 

1 . the MS includes the emergency indication also in RAU signalling or 

2. the SGSNs use the Emergency APN information. 

For intra SGSN RAU the SGSN is already aware of the Emergency APN and possibly also emergency indication 
in case the mobile performed emergency attach. In the inter SGSN case the Emergency APN information and the 
emergency indication is delivered inside the MM and PDP context information across the Gn/Gp interface (TS 
29.060 [2]). According to question 1), however, the MS in Limited Service state shall include the emergency 
indication in RAU. 

Conclusion: The MS shall include the emergency indication in RAU signalling (Intra and Inter). 
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B) In TR 23.867 for a few procedures e.g. RAU and Serving RNS relocation, there is an editor's note stating 
that "It is FFS whether CAMEL procedures are performed if the MS is emergency attached or if the MS 
has active PDF context(s) for an emergency use". 

The CAMEL TDPs seems to be applicable, but most probably there is no real need for any CAMEL 
functionality in those cases. 

Working Assumption: Keep the CAMEL TDPs as is and let operator configuration decide whether the TDPs are 
invoked or not. 

C) What level Emergency calls will work with pre-REL-7 SGSNs? 

The Rel-7 MS that supports IMS emergency services shall be able to insert the emergency indication (new Rel-7 
information) in the PS attach, RAU and combined procedures and to request Emergency APN (new in Rel-7). 
The Rel-7 GPRS network that supports IMS emergency services shall be able to interpret and handle these new 
emergency indications from the UE. 

Conclusion: Pre-Rel-7 SGSNs do not support IMS emergency services. 

D) Are combined procedures applicable if IMS emergency services are in use (Attach and RA/LA Updating)? 

Clause 7.3 of the present document refers to TS 22.101 [8], clause 10.1.2 that specifies that "A CS and IMS 
capable UE attempting an emergency call should give priority to the CS Domain. In case the call attempt fails, 
the UE should automatically make a second attempt on the other domain". 

The GPRS network may send an indication that the combined PSh-CS procedures are to be used by all MS in that 
network. 

Conclusion: The combined procedures (Attach and RA/LA Updating) shall support IMS emergency services. 

NOTE 1 : It is FFS if a new message type for combined emergency Attach is needed. 

NOTE 2: It is FFS if a new message type for Routing Area Update is needed. 

NOTE 3: A UICC less UE that initiates an emergency access does not use combined procedures. 

E) Procedures for UlCC-less IMS emergency Attach 

Principles to be followed during Attach are described in subclause A. 6 Selection of method for UlCC-less 
emergency calls. 

Conclusion: The UlCC-less UE is always DEREGISTERED by default. Thus, when the UlCC-less UE initiates 
an emergency access, it shall do Attach with the emergency indication included. 

NOTE 4: It is FFS: whether a new message type for emergency Attach is needed. 

F) Selection rules for Emergency APN 

In order to handle the Emergency APN it is necessary to modify the decision logic of Annex A in TS 23.060 [2] 
in Rel-7, such that the SGSN supports the special Emergency APN for all users explicitly, without any need for 
the user to subscribe to the Emergency APN. This is useful in cases where e.g. the user tries to make the 
emergency call even though his or her MS is barred from all PS services. Further, this removes the necessity to 
store the Emergency APN in every single subscriber's subscription in the HLR, thus saving a great deal of 
memory in the HLR. 

Conclusion: The APN decision logic specification in TS 23.060 [2], Annex A, has to be modified for Rel-7. 

G) Impacts on Intra and Inter System change in case not all access systems support IMS emergency services 
(A/Gb mode, lu-mode) 

Changes in the specifications are needed in order to handle Intra and Inter system GPRS changes for IMS 
emergency services in Rel-7. It is not seen possible to have any IMS emergency interworking with access 
networks that do not support IMS emergency services. 
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Conclusion: IMS emergency services needs to be supported during Intra and Inter System changes in Rel-7 
access networks that support IMS emergency services. The IMS emergency service has to be released during an 
Intra or Inter system change to an access network that do not support IMS emergency services. 

H) In TR 23.867 the statement that the security functions are optional is repeated for a number of 
procedures, even though the function already is optional. 

It is seen that the existing security functions should be applied as specified in TS 23.060 [2] when a "normal" UE 
(not in limited-service-state) equipped with a valid UICC is used for making the IMS emergency call. It is noted 
that the SGSN handling of the emergency APN in VPLMN allows emergency calls to be supported in VPLMN 
even in case the UE would not get any normal PDF context in that VPLMN. The security related functional 
requirements for UlCC-less terminals are specified in clause A.6.2 below. 

Using the GGSN static filters or PCC methods it is possible for the PS core to ensure that the UE or terminal 
does not use the PDP context established for the emergency call for any other purposes. 

Conclusion: This issue will be resolved when the TS 23.060 [2] CRs are prepared based on the security related 
functional requirements and with guidance from 3GPP SA WG3. 

I) Treatment of a UE that is not registered and GPRS network selection 

The assumed scenario where this question applies is for example when the UE is powered on for the first time in 
a country and the user simultaneously initiates an IMS emergency call. In this case the UE could try to request an 
anonymous IMS emergency call immediately in any detected PLMN, but that would probably not be the best 
solution since the network may reject anonymous IMS emergency calls. 

Conclusion: When the UE with a valid UICC is powered on and the user simultaneously requests an IMS 
emergency call, the UE shall perform PLMN selection according to TS 22.01 1 and TS 23.122 and request GPRS 
emergency attach in the selected network based on network mode of operation. The user may do a manual 
network selection anytime and in such a case the UE shall follow the manual PLMN selection requirements of 
TS 22.01 1 and TS 23.122. If an emergency call is made prior to attach to that network, the UE shall request 
emergency attach. 

TS 23.122 seems to apply as such for UEs with valid UICC requesting IMS emergency services. However, 
TS 23.122 needs to be revised to allow IMS emergency services for UEs without a valid UICC and for UEs in 
"forbidden Location Areas", "forbidden PLMN", etc. The following clauses of TS 23.122, version 7.5.0, seem to 
be affected: 3.4.2, 3.5, 4.4, 5, table 2, and so on. 

J) Continued support of location (where required) following handover to a new SGSN 

If the emergency session is handed over to a new SGSN - e.g. according to the A/Gb PS mode handover 
procedure defined in TS 43.129 or the UMTS procedure defined in TS 25.936 and TS 23.060 [2], then some 
further refinements to support the PS-NI-LR procedure may be needed when this procedure is used. For 
example, if the initial location of the UE was already sent to a GMLC by a previous SGSN using a PS-NI-LR, 
the new SGSN should not re-invoke another PS-NI-LR. On the other hand, the GMLC needs to know the 
address of the new SGSN in case an updated position estimate is required using a PS-MT-LR. This might be 
solved by adding both the GMLC address and an indication of whether an initial location estimate was already 
sent to the GMLC to the emergency PDP Context Information included in the Forward Relocation Request 
(defined in 3GPP TS 29.060) which is sent from the old SGSN to the new SGSN when a handover is started. 
The inclusion of the GMLC address avoids the possibility that based on different location information (e.g. new 
cell ID), the new SGSN selects the wrong GMLC for a PS-NI-LR. The indication of initial location performance 
tells the new SGSN whether besides sending its address to the GMLC (e.g. using a PS-NI-LR), it should also 
obtain and send a location estimate. During the handover itself, the old SGSN can refrain from performing 
location to ensure that the information sent in the Forward Relocation Request remains correct. These impacts 
affect core GPRS speciications. 

Answer: Enable transfer of an indication as to whether a PS-NI-LR procedure was already performed or not 
together with the GMLC address from an old to new SGSN during handover of an emergency session. 

Exact mechanism for information transfer to the new SGSN is FFS. 
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A. 6 Selection of method for UlCC-less emergency calls 
A.6.1 GPRS considerations for IMS Emergency sessions 

In GPRS, before IMS emergency session establishment, the UE performs an emergency attach if the UE is not attached 
to the network. The UE indicates the emergency attach by including an emergency indication to the Attach Request 
message. The network applies special treatment in case of the emergency attach procedure. After a successful 
emergency attach, only PDF context requests for emergency use shall be accepted by the SGSN. It is assumed that an 
already GPRS attached UE does not detach and re-attach for emergency services. If the UE is not equipped with an 
UICC, the UE performs the Emergency Attach using the IMEI. In this case the SGSN checks whether such an 
anonymous Emergency Attach is allowed. If this is not allowed, the Emergency Attach is rejected. 

At GPRS level the mechanisms for establishing a bearer for emergency use should not differ much from the normal 
GPRS bearer establishment currently specified by 3GPP. In fact there is only a need for the network to be able to detect 
the emergency use and to be able to give special treatment to these bearers. 

As a minimum emergency sessions and bearers for them should not be dropped, so emergency bearers may require 
enhanced QoS, e.g. higher priority than subscription based priority. 

The UE establishes a bearer for emergency use by including the globally dedicated emergency APN during PDP context 
activation. PDP context modification and PDP context deactivation procedures are not affected. 

A.6.2 Emergency Calls in absence of UICC for GPRS Access 

The UE shall follow the procedures described below using the IMEI as the identity to access GPRS in the absence of an 
UICC. 

The UlCC-less MS is DEREGISTERED by default and shall therefore do Attach including the emergency indication 
when requesting access for the IMS emergency service When the UICC is not present or the UICC is not valid, the ME 
shall identify itself in the Attach signalling by the IMEI in the same way as in the CS domain (the CM Service Request), 
see TS 24.008 [13] for more details. 

NOTE 1: A UICC that is not valid is a UICC that in spite of being inserted is blocked for use, e.g. due to attempted 
access by a wrong pin-code or lack of roaming agreements. 

NOTE 2: It is FFS how to use the EIR to blacklist certain IMEIs with frequent junk emergency calls. 

NOTE 3: TS 23.122 needs to be revised to allow IMS emergency services for UlCC-less MS. 

NOTE 4: It is FFS: whether a new message type for emergency Attach is needed. 

As neither authentication nor ciphering functionality can be performed there is no need to communicate with any HSS. 
After successful attach, the mobile shall continue with emergency session establishment. The above ensures that the 
existing GPRS procedures can be used without any major system impacts both in the network and the UE. 

The UE shall not accept other numbers than the numbers stored in the ME as valid number for an emergency calls. 

The emergency call application determines whether the CS emergency call or the IMS emergency call shall be used in 
the same way regardless whether the UICC is valid or not. 
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In order to support emergency calls from UlCC-less terminals and UEs in limited-service-state (see TS 23.122) there is 
a need to specify a method for the UE to get emergency access to GPRS, otherwise such terminals will not be accepted 
in the network. There are also benefits if the emergency access method is used by "normal" UEs in PMM-idle mode. 
The requirements related to the emergency access method are specified below with additional comments. 

Functional requirements for the emergency access method: 

1 . The emergency access method should be the same for UlCC-less terminals, UEs in limited-service-state and for 
UEs in PMM-idle mode. 

2. Existing security functions should apply when possible: 

UEs with valid UICC are able to support standard security functions even when roaming in a forbidden PLMN 
or forbidden area. But in some scenarios the network will not be able to initiate the security functions, e.g. a non- 
roaming partner VPLMN is probably not able to get the authentication credentials and keys from the HSS of the 
UE in a forbidden area (i.e. in limited-service-state). 

3. The level of security for UlCC-less terminals and UEs in limited-service-state making a IMS emergency call 
shall not be any different from that of a UlCC-less terminal or UE in limited service state making a CS 
emergency call. 

4. Pre-Rel-7 SGSNs cannot support the emergency access method and the attempted emergency call from terminal 
should be rejected as soon as possible. 

5. After the emergency call is cleared, the terminal should resume normal idle mode behaviour. 
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Annex B (informative): 

IIVIS emergency sessions over 3GPP/WLAN Interworking (I- 

WLAN) 

B.1 Void 
B2. Void 
B.3 Location handling for l-WLAN 

If the UE has location information available, the UE should include the location information in the SIP INVITE request 
to establish an emergency session. The UE using WLAN access may use the identifier of the access node (e.g. the MAC 
address of the WLAN Access Point) as the Location Identifier. WLAN UE Originated Procedure in I-WLAN procedure 
defined in TS 23.271 [5] is applicable to obtain location information. 

For regions (e.g. North America) in which an interim location may be required to assist routing to the correct PSAP 
and/or where accurate initial and updated location information may be required, the IW-MT-LR without HLR/HSS or 
AAA Query procedure defined in TS 23.271 [5] is applicable. 
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Annex C (normative): 

IMS emergency services using Fixed Broadband Access 

C.1 Location Retrieval for emergency services over fixed 
broadband access 

These procedures described in this annex apply when the IP -CAN contains a Network Attachment Subsystem with a 
CLF as specified in ETSI ES 282 004 [18]. 

C.1 .1 High Level Principles for Emergency location information for fixed 
broadband access 

In addition to the architecture described in clause 5.1 above, the P-CSCF has an interface to an LRF which may contain 
a CLF as described below in figure C.1. For more information on the CLF refer to ETSI ES 282 004 [18]. 



LRF 



Mq (e.g., e2) 



P-CSCF 

Figure C.1 : Additional P-CSCF interface for fixed broadband access 

For fixed broadband access, the UE may know its own network location or geographical location. If the UE knows its 
location, it shall insert the location information in the SIP INVITE request when establishing the emergency IMS 
session. 

As an alternative, if the UE is not able to determine its own location, the UE should try to request its location from the 
access network. The access network may know the location of the access point where the UE is connected to. The UE 
should request the location information from the access network according to clause 7.6. The UE shall insert the 
location information received as a response to the location query in the emergency SIP INVITE request. This location 
information may be network based, e.g. line identification, or geographical location information. 

If the UE does not know its location and is unable to obtain its location from the access network, the UE should have a 
means to indicate in the emergency SIP INVITE that its location is unknown. 

If the UE does not provide location information, the P-CSCF may request location information from the LRF as 
described in clause 7.6 and insert the location information in the received INVITE request. The IMS network may also 
request location information from the LRF in the case that verification of the location information provided by the UE is 
required. After such verification, the IMS network may insert the location information received from the LRF or 
override the location information received from the UE before routing the request to the PSAP. 

Editor's Note: How the IMS network routes the emergency session based on location information is FES. 

Editor's Note: Emergency location information for I-WLAN will be placed in a separate subclause. 
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C.1 .2 Retrieval of location information for emergency services over fixed 
broadband access 

In addition to subclause 7.6, the following applies for a fixed broadband access: 

When the UE is requesting to retrieve the location information from IP-CAN, the UE may use the DHCP option 
for coordinate-based geographic location of the client as specified by IETF in RFC 3825 [9] and the DHCP 
option that allows hosts to learn their civic location via DHCP, as specified in the draft-ietf-geopriv-dhcp-civil- 
06 [10]. This DHCP option shall not be used by an UE on an IP-CAN using 3GPP RAT. 

Editor's Note: The implications when there is a NAT between the UE and the DHCP server is FES. 

The line identifier used by the UE with fixed broadband access may be authenticated by the IMS core. 
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Annex D (informative): 

Examples of call flows according to NENA 12 

recommendations 

This section provides the examples of call flows according to NENA 12 recommendations [17]. 

D.1 ECS redirecting IMS emergency call 



E-CSCF 



ECS 



MGCF/MGW 



PSAP/EC 



1. An IMS emergency 
call Is Initiated 



2. Invite (911/112, 

LO, Initial SDP 
offer) , 



3. Redirect (ESRI^ 
^ ESQK, LRO) 



6. SubscrlbeEvent 



7. ACK 



4. Invite (ESRN/LRO, ESQK, Initial SDP) 



5. Session Setup continues to the 
PSAP/EC with ESQK as CBN 



8. Intermediate Signalling to Establish Connection 



9. PSAP retrieves location 

from Location Server as 

necessary 



10. Call Termination Signalling 



1 1 . EventNotlflcatlon 



12. ACK 



Figure D.1 

This flow is supported by the procedures in clause 7.3, where the E-CSCF need not enquire the LRF for location 
information. Additional steps defined here are standard SIP methods, but not defined in this specification. 
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Detailed description of the procedure: 

1) An IMS emergency call is initiated. 

2) The E-CSCF sends an Invite message with 911 or other well known emergency number as the dialed number, 
the UE's location information in a Location Object (LO) if available, and the UE's media capabilities 
encapsulated in a SDP payload, to the ECS. 

3) Based on the received Location Object (LO), the ECS will determine to which PSAP/EC the call should be 
routed and allocate an ESQK from the ESQK pool associated with that particular PSAP/EC. The ECS then will 
format a SIP response with the retrieved ESRN/ESQK in the Contact fields to redirect the emergency call. 

4) The IMS Core uses the ESRN/ESQK received in the call redirect message to format an INVITE message 
properly, and sends it to the MGCF/MGW. A P-Asserted-Identity field may be inserted in the INVITE message, 
it contains either an ESQK or the CBN. 

5) The emergency call setup continues with the PSAP/EC. 

6) The ECS initiates a subscription at the IMS Core to request a notification of call termination of the emergency 
call. 

7) An acknowledgement is returned. 

8) The emergency session establishment signalling continues. 

9) The PSAP retrieves location from the ECS. 

10) The emergency session is released. 

1 l)The IMS Core sends an EventNotification message to the ECS with an Event indicating that the 911 call has 
been terminated. At this time, the ESQK allocated to the emergency session can be released. 

12) An acknowledgement is returned to the IMS Core. 
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D.2 ECS routes the emergency call to the gateway with 
record route 



E-CSCF 



ECS 



MGCF/MGW 



1. An IMS Emergency 
call Is Initiated 



2. Invite (91 1/112, 

LO, Initial SDP 
offer) , 



3. Invite (ESRN, 

ESQK, Initial SDP 

offer) 



PSAP/EC 



4. Continue call setup to PSAP/EC 



5. Intermediate Signalling to Establish Connection 




6. PSAP retrieves location 

from Location Server as 

necessary 



n-^ 


r -^ 


r ^r 


7. Call Termination Is Initiated 




8. Hangup 










9. SIP OK 










10. Rest of Call Termination signalling 













Figure D.2 

This flow is supported by the procedures in clause 7.3, where the E-CSCF need not enquire the LRF for location 
information. 

Detailed description of the procedure: 

1) An IMS emergency call is initiated. 

2) The E-CSCF sends an Invite message with 91 1 or other well known emergency number as the dialled number, 
the UE's location information in a Location Object (LO) if available, and the UE's media capabilities 
encapsulated in a SDP payload, to the ECS. 

3) Based on the received Location Object (LO), the ECS will determine to which PSAP/EC the call should be 
routed and allocate an ESQK from the ESQK pool associated with that particular PSAP/EC. The ECS then re- 
issues an Invite to an appropriate MGCF/MGW with the ESRN/LRO, ESQK and a record route indication, or the 
call to be routed to PSAP the P-Asserted-Identity contains ESQK, A P-Asserted-Identity field may be inserted in 
the INVITE message, f for the call to be routed to other emergency answering centre the P-Asserted-Identity 
contains the CBN. 
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4) The emergency call setup continues with the PSAP/EC. 

5) The emergency session establishment signalling continues. 

6) The PSAP retrieves location from the ECS. 

7) Either the caller or PSAP initiates the call termination signalling. 

8) The E-CSCF or MGCF/MGW forwards the hangup message to the ECS. At this time, the ESQK allocated to the 
emergency session can be released. 

9) The ECS sends an OK to the E-CSCF or MGCF/MGW. 

10) The call termination signalling continues. 
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